PrizmDoc
Migrating to PrizmDoc Application Services (PAS)

For existing customers of PrizmDoc who have already done the work to integrate the Viewing Client into their applications, there is naturally a question about how to, and perhaps more importantly, why migrate to the new PrizmDoc Application Services architecture.

The first thing to know about PrizmDoc Application Services is that there is no requirement that your application migrate to use it. PrizmDoc Application Services makes use of the same RESTful API that your application currently supports, and that won’t change in the future (although we will likely augment this API over time to include more functionality).

However, there are several strong reasons why it’s beneficial to make the switch and use PrizmDoc Application Services:   

How to Migrate to PrizmDoc Application Services

The work needed to migrate your application to PrizmDoc Application Services can range from simply overriding several routes in your web server’s configuration to having to override several functions from the PrizmDoc Application Services implementation and redirecting them to your own. See which one of the following scenarios best explains your situation:

Scenario 1

If your application has used the web sample code we’ve provided in the past without modifications, then the migration path is simple: install PrizmDoc Application Services and see the help article on how to configure it for your particular web server.

Scenario 2

If you are using a custom storage mechanism for your documents, but not markup files, you might be in a situation where you are using a custom markup id when creating a session. In the previous samples, this is the value of origin.documentMarkupId. If this is the case, you can update your code for creating a session to use the PrizmDoc Application Services ViewingSession API instead of interacting with the PrizmDoc Server. You can provide the same value to source.markupId, allowing PrizmDoc Application Services to use the same custom ids you have used in the past. For more information, see the PrizmDoc Application Services Viewing Session API.

Scenario 3

Things begin to get more complicated if you’ve implemented your own storage mechanism for annotations and/or image stamp files. While PrizmDoc Application Services will be backward compatible with these files when created by our web samples, there’s no way for it to know how you’ve stored your own documents. In this case the only recourse is to override the appropriate calls into PrizmDoc Application Services with calls to your own code to handle persistence.

Note that even in this scenario you can take advantage of most of PrizmDoc Application Services functionality, as you’ll only be overriding a few functions at most.

 

 


©2016. Accusoft Corporation. All Rights Reserved.

Send Feedback